linux_testing: enable Rust by default if available#345980
linux_testing: enable Rust by default if available#345980alyssais merged 3 commits intoNixOS:staging-nextfrom
Conversation
|
What happens on other targets now that we unconditionally enable Rust? |
|
Could we just enable it on aarch64 and x86_64? I'm not sure if it even supports other arches rn/if we can easily test other arches. |
Ma27
force-pushed
the
linux-testing-rust-aarch64
branch
from
2619a51 to
fec2614
Compare
|
Yeah good point, was too focused on getting the aarch64 build done :) |
ofborg
bot
added
10.rebuild-darwin: 0
Generally we don't limit functionality for other architectures just because we can't test it — I'm not aware of any other architecture-specific issues, so I think this should be enabled in all cases where we have a Rust compiler available, assuming we can cross compile kernels for a couple of other architectures. (See gstreamer for an example of how to do this check.) Otherwise, other architectures lag behind, and things fail on them for confusing and unnecessary reasons due to this sort of divergence. |
|
I pushed a potential fix by making the support for CONFIG_RUST by dsefault dependant on whether rustc supports the host platform. For testing purposes, I decided to build it for powerpc64le (built successfully) and riscv64 which failed to build with This is known and apparently riscv specific: https://lore.kernel.org/lkml/31885EDD-EF6D-4EF1-94CA-276BA7A340B7@kernel.org/T/ Anyways, is this (i.e. |
vcunat
changed the title
I wouldn't worry about this one for now. |
|
Although I guess if we're fixing the conditional anyway, might as well add a |
Ma27
force-pushed
the
linux-testing-rust-aarch64
branch
from
d5bfe60 to
68e45b4
Compare
The first assumption[1] we had was that the `aarch64-unknown-none` target was missing from rustc and that this was the cause for the regression. However, it turns out that the relevant code from `rustc` wasn't used anyways because the Makefile does `--sysroot /dev/null`[2] which prevents rustc from using its own libcore. So luckily we don't have to patch the Rust bootstrap to get aarch64-linux back working[3]. In fact, the Rust part seems broken for both 6.10 and 6.11[4], but I decided to not bother since none of those are longterm versions. So all that's left here is to enable Rust for aarch64-linux because it clearly works[5]. [1] NixOS#315121 (comment) [2] https://lore.kernel.org/all/20231031201752.1189213-1-mmaurer@google.com/ [3] Of course I only realized this _after_ I spent some time hacking a rustc patch together 🙃 [4] This broke with error[E0463]: can't find crate for `core` | = note: the `aarch64-unknown-none` target may not be installed = help: consider downloading the target with `rustup target add aarch64-unknown-none` = help: consider building the standard library from source with `cargo build -Zbuild-std` [5] While the build is fine, the VM tests are still panicking, but that's also the case for `kernel-generic` because of a 9p regression: switch_root: can't execute '/nix/store/zv87gw0yxfsslq0mcc35a99k54da9a4z-nixos-system-machine-test/init': Exec format error [ 1.734997] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 1.736002] CPU: 0 UID: 0 PID: 1 Comm: switch_root Not tainted 6.12.0-rc1 #1-NixOS [...] Reported as https://lore.kernel.org/all/D4LHHUNLG79Y.12PI0X6BEHRHW@mbosch.me/T/#u
This breaks the build like this:
/nix/store/f3k0rdhcd2cx57phx755c2xixgifw5m5-binutils-2.42/bin/ld: Unexpected GOT/PLT entries detected!
/nix/store/f3k0rdhcd2cx57phx755c2xixgifw5m5-binutils-2.42/bin/ld: Unexpected run-time procedure linkages detected!
/nix/store/f3k0rdhcd2cx57phx755c2xixgifw5m5-binutils-2.42/bin/ld: fs/nfs/localio.o: in function `nfs_local_iocb_alloc':
/build/source/build/../fs/nfs/localio.c:290:(.text+0x324): undefined reference to `nfs_to'
[...]
Reported as https://lore.kernel.org/all/D4OUJRP8YWRM.ATQ7KASTYX5H@mbosch.me/
* It doesn't matter if `rustc` is available, but if rustc can compile to the hostPlatform. So use a custom condition instead of `availableOn`. * Explicitly exclude the combination of GCC and riscv which is known to be broken[1]. [1] https://lore.kernel.org/lkml/31885EDD-EF6D-4EF1-94CA-276BA7A340B7@kernel.org/T/ Co-authored-by: Alyssa Ross <hi@alyssa.is>
Ma27
force-pushed
the
linux-testing-rust-aarch64
branch
from
68e45b4 to
067f0b5
Compare
|
@ofborg build linux_testing |
4 participants
The first assumption[1] we had was that the
aarch64-unknown-nonetarget was missing from rustc and that this was the cause for the regression.However, it turns out that the relevant code from
rustcwasn't used anyways because the Makefile does--sysroot /dev/null[2] which prevents rustc from using its own libcore. So luckily we don't have to patch the Rust bootstrap to get aarch64-linux back working[3].In fact, the Rust part seems broken for both 6.10 and 6.11[4], but I decided to not bother since none of those are longterm versions.
So what's left here?
Enabling Rust for aarch64-linux because it clearly works[5].
Turning off NFS_LOCALIO for aarch6y4-linux because breaks the build like this:
[1] #315121 (comment) [2] https://lore.kernel.org/all/20231031201752.1189213-1-mmaurer@google.com/ [3] Of course I only realized this after I spent some time hacking a rustc
patch together 🙃
[4] This broke with
[5] While the build is fine, the VM tests are still panicking, but
that's also the case for
kernel-genericbecause of a 9pregression:
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.